IBIS Macromodel Task Group Meeting date: 1 September 2009 Members (asterisk for those attending): Adge Hawes, IBM * Ambrish Varma, Cadence Design Systems * Anders Ekholm, Ericsson * Arpad Muranyi, Mentor Graphics Corp. Barry Katz, SiSoft * Bob Ross, Teraspeed Consulting Group Brad Brim, Sigrity Brad Griffin, Cadence Design Systems Chris McGrath, Synopsys David Banas, Xilinx Deepak Ramaswany, Ansoft Donald Telian, consultant Doug White, Cisco Systems * Eckhard Lenski, Nokia-Siemens Networks Essaid Bensoudane, ST Microelectronics * Fangyi Rao, Agilent Ganesh Narayanaswamy, ST Micro Gang Kang, Sigrity Hemant Shah, Cadence Design Systems Ian Dodd, consultant Jerry Chuang, Xilinx Joe Abler, IBM John Angulo, Mentor Graphics John Shields, Mentor Graphics Ken Willis, Cadence Design Systems * Kumar Keshavan, Sigrity Lance Wang, Cadence Design Systems Luis Boluna, Cisco Systems * Michael Mirmak, Intel Corp. * Mike LaBonte, Cisco Systems Mike Steinberger, SiSoft Mustansir Fanaswalla, Xilinx Patrick O'Halloran, Tiburon Design Automation Paul Fernando, NCSU Pavani Jella, TI Radek Biernacki, Agilent (EESof) * Randy Wolff, Micron Technology Ray Komow, Cadence Design Systems Richard Mellitz, Intel Richard Ward, Texas Instruments Samuel Mertens, Ansoft Sam Chitwood, Sigrity Sanjeev Gupta, Agilent Shangli Wu, Cadence Design Systems Sid Singh, Extreme Networks Stephen Scearce, Cisco Systems Steve Pytel, Ansoft Syed Huq, Cisco Systems Syed Sadeghi, ST Micro Ted Mido, Synopsys Terry Jernberg, Cadence Design Systems * Todd Westerhoff, SiSoft Vladimir Dmitriev-Zdorov Vikas Gupta, Xilinx Vuk Borich, Agilent * Walter Katz, SiSoft * Zhen Mu, Mentor Graphics ------------------------------------------------------------------------ Opens: Arpad reminded us to keep discussions orderly, taking turns. -------------------------- Call for patent disclosure: - No one declared a patent. ------------- Review of ARs: - Michael M send info about parser problems found - We have already discussed all major items - Arpad send updated IBIS-ISS presentation to Walter - TBD - Mike change web page to make items easily linkable - TBD - Arpad write a BIRD to clarify time period accuracy requirements - TBD - Todd: Write IBIS s-param BIRD - No update - Arpad: Write parameter passing syntax proposal (BIRD draft) for *-AMS models in IBIS that is consistent with the parameter passing syntax of the AMI models - TBD - TBD: Propose a parameter passing syntax for the SPICE - [External ...] also? - TBD - Arpad: Review the documentation (annotation) in the macro libraries. - Deferred until a demand arises or we have nothing else to do ------------- New Discussion: Walter showed his document "IBIS 5.0 Parser Clarification BIRD": - This contains responses to an email from Bob - Arpad: Is there a completed BIRD document? - Walter: No, the formal boilerplate requires more work - This document summarizes the meat of the changes - Arpad: So the highlighted changes will answer the parser developer's questions? - Walter: It should - Bob: The parser project is coming to a close - Not sure what the status is now - It may be the only parentheses will be checked - Michael M: The developer has had no direction regarding AMI so far - It may be best to have him in this call - Bob: We should make a few simple rules and send those - We don't want to undo any work done so far - We don't have time to get him on the phone - There is no guarantee AMI checking will get into the first release - The parser will be released on a reasonable time frame, regardless - Walter: I tried to come up with a simple set of rules - Will all EDA vendors support this? - Ambrish: The current spec has enough to go by - One small deduction from it will be fine - We must decide if Default will be the Value when Value is absent - Walter: The developer seems to feel there is a problem - Kumar: So Default will be required then - Ambrish: Yes - If we can agree about Default that will solve all parser issues - Kumar: What about Model_specific? - Ambrish: There is no issue for Model_specific - Walter: What would go wrong with my proposal? - Ambrish: Nothing, but it is not needed - Arpad: I have no preference either way - Walter: If something is type Info it requires Format or Default - Ambrish: The spec has enough language already - We only need to agree about the usage - What prevents the parser from working? - Walter: I can show a number of contradictions next week - Arpad show page 144 of the IBIS 5 document - Ambrish: 5 params are shown under (parameter_name ... - Michael M: I have parser outputs sowing problems - Can I show material from SiSoft's example? - Todd: Yes Michael M showed a parser output example: - Michael M: Errors are shown, with the developer's comments - For example, Default is supposed to be mandatory for Init_Returns_Impulse - I don't see the requirement - Bob: The developer is wrong - Ambrish: The spec does not say Default is required for that - Todd: Are these 5 errors with data from the latest toolkit? - Michael M: No, I can ask for that - Todd: We did not use Format or Default for reserved parameters - Bob: We should tell the developer to not print those warnings - Todd: Only Tx_jitter and Tx_DCD require Format - Reserved parameters are all boolean, why have Type and Format? Michael M showed an earlier email from Atul: - Michael M: It shows inconsistent implications about Format requirements - Bob: We can make the rule that Format is required for all else - Walter: For the 1st 5 params Default is required and Format is not allowed - and they are optional for all others - Ambrish: That is not correct - Todd: To clarify, "1st 5" means the reserved params in table 3 - Ambrish neglected the case where Format has some Value and Default has some other value - For example Value might allow only 6 but Default could be 5 - Walter: If Format allows only one value, why not use Default? - Ambrish: We need to fix that - Walter: My proposal fixes the problems easily - Todd: We have to be clear whether we are interpreting IBIS 5 as written or changing it - Walter: We are interpreting what 5 really means to say - Todd: What should Init_Returns_Impulse look like? - Walter: Format Boolean, Default FALSE - As written it could say (Format Value FALSE) - It will be difficult to act differently based on which param it is - Michael M: Is the table correct? - Ambrish: It is incorrect - Bob: It violates what is said earlier, but is informational - We could have a warning if we over-specify - Some of this might be to setup the EDA tool interface - Ranges, for example, limit the controls - Michael M: Would it be enough to give the developer new tables? - Todd: Table 3 is not incorrect - We did not anticipate that the keyword did not apply to reserved params - Init_Returns_Impulse has to be Boolean - (Format Value TRUE) does not violate the spirit of this - Also the order of keywords does not matter - Ambrish: So we are OK if the developer does not interpret table 3 literally? - Todd: Correct - Bob: It is our fault if our spec is not clear - We should make the rule that Format is optional for the reserved params - It is not an error for it to be there - We can change the spec to include this - Kumar: The parser can issue a warning - Walter: The Default must be an allowed Value - Bob: We should work with real models and make sure they pass - Walter: Our original intent was a fixed order of keywords - it became a parameter tree tat was passed - Bob: It is not good to not require Format or Default for some Types - Todd: 2 cases: - A Reserved param like Use_Init_Output, Default is explicitly defined - Table 1 identifies the action if it does not exist in AMI file - You can't declare that parameter and not put Default - If a model writes back a float number, why would we declare a Default? - Ambrish: We are speculating about what model makers will do - Walter: Format is required for Model_specific, what is the value? - Ambrish: These are imaginary issues - Kumar: It does not make sense to have a Value after Format - Walter: Format does not make sense anywhere - Bob: Format is in the spec and we have to deal with it - The tool might override any value - We can't pay a developer to go through everything - Ambrish: These are not issues from the developer - Todd: It's a problem if a value is missing and handling for absent values not defined - Format and Default do not have much meaning for returned data - But that doesn't mean we have to stop parsing it - Ambrish: Pages 144 and 145 both have definitions, could we prefer one? - Michael M: It would help the parser to remove table 3 - Ambrish: We would want to remove Table 1 - Bob: If the Reserved param is missing we need it - It gives the allowable format - Michael M: We could remove a portion of the table - Bob: We should not remove it from the spec - Ambrish: We can tell the developer to ignore table 3 - Todd: Reserved params have to have one of Format, Default or both - the data have to be self-consistent - Walter: Why not for all parameters? - It would be simpler to understand and read - Michael M: That would be "scope creep", going beyond what is needed - Ambrish: Agree - Arpad: Isn't a simple change with some creep better than a complicated change? - Michael M: We have a legal cutoff date coming up - Bob: The parser will be done before any BIRD is finished - It is clear that Format is illegal for Reserved params - Todd: True - Michael M: It's OK if the parser leads the spec - We run out of time in October - Bob: Atul has done more work than he bid - He will be paid regardless - But getting a parser is urgent - We can allow meaningless cases and still get a good parser - The rules should be simple - Ambrish: Todd suggested Table 3 is for info only; that should do - Walter: For the first 5 Reserved params Default is required and Format is illegal - For the rest Format is required and Default is optional - Ambrish: OK - Walter: Caveat: If I have an Input text string one does not know how to create a Format for it - We can make valid AMI files that will not pass the parser - Arpad: What input would be text? - Walter: A file name - Arpad: The spec allows text passed to the DLL? - Walter: Yes - Michael M: All we need is a bug report - The developer is traveling but needs input ASAP - Arpad: What was wrong with Walter's proposal? - Bob: We decided on a different way - It contradicted an alternative proposal - The table syntax will not not be parsed - Ambrish: Walter's proposal will take 3 or more weeks - Arpad: Don't the rules we agreed on require a BIRD? - Ambrish: No - Bob: No - Mike L: Some people reading the IBIS spec didn't see it that way Arpad: We will have Kumar's presentation next week - Kumar's and Arpad's presentations are posted - The only difference is where convolution is done AR: Arpad send notice that his and Kumar's documents are posted Next meeting: 8 Sep 2009 12:00pm PT -------- IBIS Interconnect SPICE Wish List: 1) Simulator directives